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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The present document is part 2 of a multi-part deliverable covering the IP Datacast Electronic Service Guide 
implementation guidelines over DVB-H and DVB-SH as identified below: 

Part 1 : IP Datacast over DVB-H; 

Part 2: IP Datacast over DVB-SH. 



Introduction 



IP Datacast is an end-to-end broadcast system for delivery of any types of digital content and services using 
IP -based mechanisms. An inherent part of the IPDC system is that it comprises a unidirectional DVB broadcast path 
and a bi-directional mobile/cellular interactivity path. IPDC is thus a platform for convergence of services from 
mobile/cellular and broadcast/media domains. The present document gives the implementation guidelines on the use of 
the Electronic Service Guide in IP Datacast over DVB-SH system. [2] is a corresponding document guidelining on the 
use of Electronic Service Guide in IP Datacast over DVB-H system. 
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Scope 



The present document gives implementation guidelines on the use of the electronic service guide in IP Datacast over 
DVB-SH system ([4] to [6]) for the announcement of services to the terminal. 

The present document intends in particular to guide implementers of IP Datacast over DVB-SH Services, Servers and 
Terminals to make best use of the specification IP Datacast over DVB-H: Electronic Service Guide 
TS 102 471 [3]. The present document must also be considered as complementary to the ESG implementation 
guidelines applicable in DVB-H context (TS 102 592-1 [2]), in particular for supporting ESG regionalization, one of the 
specific features provided by a DVB-SH network. These implementation guidelines apply to both "DVB-H ESG phase 
1" defined in TS 102 471 (Vl.2.1) [1] and "DVB-H ESG phase 2" defined in TS 102 471 [3]. These two versions of the 
same specification mandate in particular the use of different ESG bootstrap structures, which particularly affects some 
procedures defined in the present document. 

The present document is structured into three main clauses. Clause 4 provides an overview of hypothesis and 
requirements followed in the DVB-SH context. Clause 5 describes how regionalization can be ensured in some specific 
scenarios. Annex A provides guidance on different types of ESG implementation, including DVB-H based ESG 
implementations, and their interoperability. Annex B provides more details on the DVB-SH network physical 
capabilities. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 471 (Vl.2.1): "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: 

Electronic Service Guide (ESG)". 

[2] ETSI TS 102 592-1: "Digital Video Broadcasting (DVB); IP Datacast: Electronic Service Guide 

(ESG) Implementation Guidelines; Part 1: IP Datacast over DVB-H". 

[3] ETSI TS 102 47 1 : "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Electronic 

Service Guide (ESG)". 

[4] ETSI TS 102 585: "Digital Video Broadcasting (DVB); System specifications for satellite services 

to Handheld devices (SH) below 3 GHz". 

[5] Void. 
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[6] ETSI TS 102 584: "Digital Video Broadcasting (DVB); DVB-SH implementation Guidelines". 

[7] ETSI TS 102 832: "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Notification 

Framework" . 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] Void. 

[i.2] Void. 

[i.3] ETSI TS 102 470-2: "Digital Video Broadcasting (DVB); IP Datacast: Program Specific 

Information (PSI)/Service Information (SI); Part 2 : IP Datacast over DVB-SH". 

[i.4] ETSI TS 102 611-2: "Digital Video Broadcasting (DVB); IP Datacast: Implementation Guidelines 

for Mobility; Part 2: IP Datacast over DVB-SH". 

[i.5] Void. 

[i.6] Void. 

[i.7] Void. 

[i.8] ISO/IEC 13818-1: "Generic coding of moving pictures and associated audio information: 

Systems". 

[i.9] Void. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

acquisition information: information necessary to acquire a service or content 

common service: service available on all cells where the TS is transmitted 

content: atomic content part of the service described, and scheduled separately 

delivery area: abstract area enabling to decouple the generation of regionalized ESGs from the knowledge of physical 
transmission areas 

NOTE: The ESG provider defines delivery areas and binds the IP streams scoped by an ESG to these delivery 
areas. Some network entity binds these delivery areas to cells in the network, via DVB service 
management and SDT generation. 

delivery area ID: integer value uniquely identifying a delivery area in the scope of a {TS, ProviderURI } 

elementary stream: stream of transport packets within a transport stream sharing a common Packet Identifier (PID) 

NOTE: The elementary stream definition differs from the one defined in MPEG-2 (ISO/IEC 13818-1 [i.8]). 
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ESG access descriptor: in the bootstrap session, descriptor providing the link between the declaration of the ESGs (in 
the ESG ProviderDiscovery descriptor) and their respective acquisition entry point (the announcement carousel) 

ESG announcement carousel: FLUTE session used as an entry point by the terminal to acquire a given ESG 

ESG auxiliary data: ESG data, which is referenced from an instance of the XML based data model, e.g. an SDP file, 
an HTML page or a PNG file 

NOTE: Even though SDP files can be considered as ESG auxiliary data, it is possible to transport them within the 
ESG fragment stream or as files within a FLUTE session. 

ESG bootstrap session: FLUTE session used as an entry point by the terminal to discover the ESGs available in a 
given IP platform of the actual TS 

ESG container: structure to group ESG data into one transport object for delivery purposes 

ESG Entry: in the ESG Access descriptor, entry providing the tuning parameters of one announcement carousel 

ESG fragment: fragment of ESG data delivered in the ESG fragment stream and referred to by a fragment reference in 
the encapsulation structure 

NOTE: Namely an ESG fragment can be an ESG XML fragment, ESG auxiliary data or private auxiliary data. 

ESG Fragment ID: URI uniquely identifying a fragment in one ESG 

ESG init container: ESG container carrying data structures for initialization, such as the ESG init message and the 
ESG main fragment 

ESG init message: initialization information to decode ESG fragments 

ESG phase 1: ESG as specified in TS 102 471 Vl.2.1 [1], utilizing version 1 ESG bootstrap descriptors, and for which 
ESG identification is based on ProviderURI 

ESG phase 2: ESG as specified in TS 102 471 [3], utilizing version 2 ESG bootstrap descriptors, and for which ESG 
identification is based on ESG_URI 

ESG ProviderDiscovery descriptor: in the bootstrap session, descriptor providing information on ESGs available in a 
given IP platform of the actual TS 

ESG session partition declaration: tells the terminal, how the ESG is partitioned in ESG Sessions, what are the 
partitioning criteria for each session 

ESG XML fragment: ESG fragment of an XML instance which is an instantiation of a data type 

NOTE: A Hmited set of ESG XML fragment types have been defined in TS 102 471 [3]. 

IP/MAC stream_location_descriptor: INT descriptor providing the locations of the instances (IP streams) of one IP 
flow in the actual Transport Stream and the neighbouring Transport Streams 

NOTE: This descriptor is especially used by the terminal to perform two procedures: 

■ IP address — > PID resolution; 

■ handover decision making. 

IP platform: set of IP flows managed by an organization 

NOTE: The IP platform represents a harmonized IP address space that has no address collisions. The concept of 
IP platforms is described in more detail in TS 102 470-2 [i.3]. 

IP flow: flow of IP datagrams each sharing the same IP source and destination address 

Local service: service available on some cells (but not all cells) where the TS is transmitted 

private auxiliary data: data of which the format is not specified in TS 102 471 [3] 
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providerURI: unique identifier of an ESG Provider 

NOTE: In the case of ESG phase 1, it also uniquely identifies one ESG. 

providerlD: integer value used as a shortcut to designate a ProviderURI 

purchase channel: purchase system, through which a service may be purchased 

purchase information: information to display to the user that a service needs to be purchased and the information that 
is necessary to access and acquire rights to consume a service or content 

purchase item: service bundle to which pricing information is attached 

schedule event: broadcast event which is described separately 

service: offer from a service provider and has media content related to it 

service: service offering e.g. Broadcast TV Channel, soap opera service 

servicelD: fragment identifier of a Service fragment. It can also be a partition criterion in the ESG session partition 
declaration 

service_availability_descriptor: SDT descriptor that may be included in a service entry of an SDT sub-table, to signal 
that the related DVB service is subject to cell-based transmission restrictions 

service bundle: group of services composed respectively offered by a single party 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

DVB Digital Video Broadcasting 

DVB-H Digital Video Broadcast - Handheld 

DVB-SH Digital Video Broadcast - SatelUte to Handheld 

EDN ESG Default Notification 

ESG Electronic Service Guide 

FLUTE File deLivery over Unidirectional Transport 

lANA Internet Assigned Numbers Authority 

ID IDentifier 

INT IP Notification Table 

IP Internet Protocol 

IPDC IP DataCast 

MPEG Moving Picture Expert Group 

NIT Network Information Table 

NS Notification Service 

paTS partially available Transport Stream 

PID Packet IDentifier 

PMT Program Map Table 

PNG Portable Network Graphics 

PSI/SI Program Specific Information/Service Information 

RFC Request For Comments 

SDP Session Description Protocol 

SDT Service Description Table 

SEN Single Frequency Network 

SRN Service Related Notification 

TS Transport Stream 

TSI Transport Session Identifier 

TV Television 

URI Uniform Resource Identifier 

WEB last part of worldwide WEB 

XML extensible Markup Language 
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Hypothesis 



The DVB-SH provides different possible physical network configurations described in TS 102 584 [6], some of which 
are recalled in annex B. 

In terms of ESG, SFN configuration (DVB-SH A SFN) is actually strictly identical to DVB-H ESG phase 1 and 
phase 2. Non-SFN configurations however differ in the sense that two frequencies (the satellite and the terrestrial) are 
used to distribute same TS. Therefore, due to the possibility to configure the physical layer differently between the two 
frequencies, some form of content regionalization is possible and described in TS 102 584 [6]. In this case, ESG is more 
complex than DVB-H ESG phase 1 and phase 2 and implies new requirements: 

• The terminal MUST be able to differentiate from the ESG what content is provided where; in particular the 
satellite content SHALL be found in any locations, whether satellite or terrestrial, whereas the local content 
MAY be available in only selected locations; this information SHOULD be available to terminals so that they 
do not, for instance, attempt to display content that is not available. 

• Satellite bandwidth MUST not be overloaded with ESG data dedicated to announce local content; therefore 
some form of "partitioning" between ESG bootstrap sessions, ESG announcement carrousels, ESG fragment 
FLUTE sessions SHALL be ensured. 

• Service continuity SHALL be possible so that a terminal moving from the satellite area to a terrestrial area 
having different ESG conditions shall be able to complement but not contradict the already received ESG by, 
e.g. the local one (and vice-versa). 

• ESG distribution SHOULD allow a terminal located on one area to receive ESG fragments pertaining to an 
adjacent area. 

To support these additional requirements, some new innovative features are introduced such as delivery areas and 
explicit and implicit ESG fragment tagging. In the rest of the present document, we shall refer to the term "ESG 
regionalization" to designate the mechanisms allowing first a global ESG instance to announce common and local IPDC 
services, and second this ESG instance to be partially delivered on some areas depending on local IPDC services 
availability as well as bandwidth considerations. The present document therefore describes the guide lining of DVB-H 
ESG phase 1 and phase 2 in order to support ESG regionalization for those DVB-SH scenarios that support it. 

It is assumed that such recommendations pertain to the only DVB-SH networks and terminals, excluding any DVB-H 
terminals to receive in any circumstances such forms of ESG instantiations. Therefore interoperability with DVB-H 
ESG is not primarily targeted although the foundations are strictly compliant and some form of compatibility between 
DVB-H ESG clients and DVB-SH ESG is possible Therefore the present document proposes several types of network 
(ESG server) and terminal (ESG client) implementations, all interoperable with each other, with some functional 
limitations in some cases. These implementations are detailed in annex A. 



5 ESG regionalization 

5.1 Detection procedure (on terminal side) 

All types of terminals (see annex A) can normally acquire non-regionalized ESGs as defined in DVB-H ESG phase 1 
and phase 2. 

In addition, for regionalized ESGs: 

• A Type terminal, although not capable of detecting that an ESG is regionalized, will seamlessly tune to the 
common announcement carousel and acquire the common components of a regionalized ESG (and in final will 
be able to tune to common IPDC services, while not being aware of the existence of local IPDC services). 
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• For ESG phase 1, a Type 1 or Type 2 terminal will detect that an ESG (identified by a given ProviderURI) is 
regionalized if for the associated ProviderlD it encounters multiple consecutive ESGentries in the ESG Access 
descriptor. 

• For ESG phase 2, a Type 1 or Type 2 terminal will detect that an ESG (identified by a given ESG_URI) is 
regionalized if for the associated broadcast AccessPointID it encounters multiple consecutive ESGentries 
(Access Points) in the ESG Access descriptor. 

5.2 Specification 
5.2.1 Overview 
5.2.1.1 Principles 

This clause presents the principles of ESG for DVB-SH. 

The partially available Transport Stream carries the IP flows of one single IP platform. 

For a given ESG Provider URI (ESG phase 1) or ESG_URI (ESG phase 2), there is one single ESG, spanning over all 
the cells on which the TS is transmitted. However, since the TS is filtered on some of these cells, only a portion of this 
ESG will be valid on one given cell (i.e. a portion of this ESG will declare IPDC services actually available on this 
cell). When moving to another cell, the terminal acquires new portions of the ESG, complementing the other portions 
acquired in previous cells. 

The received TS comprise common DVB service(s) and eventually local DVB service(s). There is no explicit signalling 
for common and local DVB services in a partially available TS, however for sure the DVB service carrying the ESG 
bootstrap FLUTE session is a common DVB service. 

A non-regionahzed DVB-SH ESG is a DVB-H comphant phase 1 or phase 2 ESG. A regionalized DVB-SH ESG is 
characterized by the presence in the ESG Access descriptor of multiple ESG Entries containing the ProviderlD (ESG 
phase 1) or the broadcast AccessPointID (ESG phase 2)associated with the ESG, each ESG Entry declaring one 
ESG announcement carousel. In the received TS, only one (one common) or two (one common, one local) of these ESG 
announcement carousels are actually transmitted, as signalled by INT and SDT. The terminal using an IP stream 
availability function (designed to check the actual transmission of some given IP stream(s) of a given IP platform ID) 
can determine which announcement carousels are actually transmitted in the TS. In case two ESG announcement 
carousels are transmitted, the terminal selects the local ESG announcement carousel, not the common ESG 
announcement carousel (how to distinguish each is specified hereafter). Indeed, the local ESG announcement carousel 
announces local and common ESG FLUTE sessions, whereas the common ESG announcement carousel announces 
common ESG FLUTE sessions only. 

The selected ESG announcement carousel declares multiple ESG FLUTE sessions via the ESG session partition 
declaration of the ESG Init Container. In this partition declaration, the declared ESG FLUTE sessions may be carried in 
any transmitted DVB service, and will at least include the common ESG FLUTE sessions (the ones carried in common 
DVB services), since all fragments delivered in common ESG FLUTE sessions are of interest on all cells. How ESG 
FLUTE sessions should be organized in the Transport Stream is guided by two considerations: firstly share FLUTE 
sessions between ESG announcement carousels whenever possible (instead of duplicating them), and secondly allow 
fine-tuned ESG complementing scenarios over broadcast channel. 

In order to decouple regionalization of ESG data from below-IP transport information and network infrastructure 
information, the concept of "delivery area" is introduced. Basically, the ESG provider groups in distinct "virtual" 
delivery areas the IP flows scoped by the same ESG instance (from ESG bootstrap session down to audio/video/key 
streams), and some entity in the network (generally the network operator) has the responsibility to bind each delivery 
area to a given set of cells in the DVB-SH network, which is technically achieved using the indirection of DVB service 
allocation and SDT generation. The delivery area is scoped by the ESG (ProviderURI for ESG phase 1, ESG_URI for 
ESG phase 2), and has a unique ID in this scope. The delivery area IDs are not used the same way on network side and 
terminal side. On network side, the TS encapsulator needs to know the delivery area ID of each session so to correctly 
decide on the grouping of IP streams in DVB services, whereas on terminal side the terminal needs only to determine 
the delivery area ID of the announcement carousels. 
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For a Type 1 terminal: 



The concept of delivery area is not directly used. The terminal first builds an implementation-specific identifier for each 
ESG FLUTE session (e.g. based on TSI, source IP address, destination IP address, etc) transmitted for the selected 
announcement carousel. Then at the time of storage, each fragment is tagged by the terminal by the identifier of the 
FLUTE session which delivered the fragment. When browsing the ESG on any cell, and knowing the ESG FLUTE 
sessions currently transmitted for the selected announcement carousel, the terminal can quickly retrieve from the stored 
ESG which fragments are presumably valid to be presented to the user, i.e. which fragments announce IPDC services 
that are actually available on current cell. However since the ESG provider may choose to deliver in ESG FLUTE 
sessions some fragments which are not valid on current cell, and since a Type 1 terminal does not know if the ESG 
provider delivers such fragments, the terminal, before tuning to any IPDC stream, must systematically check for the 
availability of these IPDC streams using an IP stream availability function. 

The tagging mechanism is called "implicit ESG fragment regionalization based on FLUTE session identifier", implicit 
because not signalled in the fragment payload itself. 

Fragments not tagged by the current FLUTE session identifiers are for sure not valid on current cell, fragments tagged 
by any of the current FLUTE session identifiers may be valid on current cell, and an additional availability check on the 
IPDC streams declared by the tagged Acquisition fragments is needed to confirm this validity. Said otherwise, this 
FLUTE session ID-based tagging reduces the number of IP stream availability checks for Type 1 terminals. 

For a Type 2 terminal: 

The concept of delivery area is directly used to determine which acquired ESG fragments of the ESG instance are valid 
on the current cell. At the time of storage, each fragment is tagged by the terminal by a delivery area ID, which 
represents the delivery area where this fragment is valid. When browsing the ESG on any cell, and knowing the IDs of 
the delivery areas it is currently located in, the terminal can quickly retrieve from the stored ESG which fragments are 
valid to be presented to the user, i.e. which fragments announce IPDC services that are actually available on current 
cell. 

The main tagging mechanism is called "implicit ESG fragment regionalization based on delivery area ID", implicit 
because not signalled in the fragment payload itself. Generally this mechanism consists in tagging the fragment by the 
delivery area ID contained in the "servicelD" criterion of the partition that declares the ESG FLUTE session delivering 
the fragment. 

However, implicit ESG fragment regionalization implies some restrictions and prevents ESG complementing scenarios 
that can help ESG acquisition service continuity. The tagging of individual fragments called "explicit ESG fragment 
regionalization based on delivery area ID" can therefore be used as a complementary mechanism. For this, ESG for 
DVB-SH proposes to encode the delivery area ID in the URI of the fragment ID, and in the URI of ESG Auxiliary Data. 

5.2.1.2 Example 

Figure 1 illustrates an example of ESG for DVB-SH in the case of ESG phase 1. Taking the case where the transmitter 
transmits the partially available TS on a cell belonging to "Terrestrial Group of Cells 1", it will transmit DVB 
services 14, 5 and 53, but not DVB service 1 1 (filtered). 

A Type terminal will behave like a DVB-H ESG client and select the first ESG Entry matching the selected 
ProviderlD. As this first ESG Entry declares the common ESG carousel 0, this terminal will seamlessly tune to this 
carousel and then to the related common ESG FLUTE sessions. The terminal will then tune to the common IPDC 
services, while ignoring the existence of local IPDC services. 

A Type 1 or Type 2 terminal will detect that the selected ESG (ProviderURI) is regionalized by the presence of multiple 
ESGentries given for the related ProviderlD. The terminal will use a (typically low-level) IP stream availability function 
to determine which announcement carousels are transmitted. Internally this function will find in the INT one matching 
target_IPxx_address descriptor for each declared carousel. The IP/MAC stream_location_descriptor of carousel 2 
(224.10.8.37) will indicate that this IP stream belongs to DVB Service 11, and service_availability descriptor in SDT 
will indicate that this DVB service 11 is filtered. Thus, the terminal can conclude that carousel 2 is not transmitted. 

From the two addresses remaining (224.3.2.04 and 224.7.1.12), the terminal will select 224.7.1.12 since appearing 
second in the ESG Entry loop. ESG announcement carousel to be monitored is then on this remaining address 
224.7.1.12 carried on DVB service 5. 
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The subsequent selection and tuning to ESG FLUTE sessions follows IPDC phase 1 rules. In order to achieve implicit 
ESG regionalization later on, the terminal needs in addition to remember some delivery information (for Type 1 
terminals: the FLUTE session identifier of each monitored ESG FLUTE session; for Type 2 terminals: the delivery area 
ID of the selected carousel, as well as, for each monitored ESG FLUTE session the delivery area ID contained in the 
"servicelD" criterion of the partition declaring this session). 
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Figure 1 : ESG phase 1 example of ESG transport in a DVB-SH partially available Transport Stream 

Some comments on figure 1 : 

• Relationship between ESG FLUTE sessions and IPDC services is not represented because this relationship is 
potentially complex (for example an Acquisition fragment distributed in an ESG FLUTE session of Delivery 
Area 1 can announce an IPDC service of Delivery Area 2 if it is explicitly tagged by delivery area ID = 2). 

• As illustrated, DVB service numbering is totally decoupled from delivery area numbering. 

• By just changing the relationship from ESG ProviderDiscoveryDescriptor to ESG Access descriptor (as per 
figure 2), figure 1 also applies to ESG phase 2. 
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5.2.2 Transport Stream, delivery areas, ESG and IPDC services 
configurations 

5.2.2.1 Transport Stream configuration 

This clause explains how the network must configure the Transport Stream in order to deploy ESG for DVB-SH. 

The Transport Stream must carry the IP streams of one single IP platform. 

The Transport Stream must be composed of the following DVB services: 

• One common DVB service or more, available on all cells (satellite and terrestrial) where this TS is transmitted. 
In order to reduce PMT bitrate, the recommended configuration is one common DVB service. 



• 



One local DVB service or more, not available on some of the cells where this TS is transmitted. On a given 
cell, zero, one or more local DVB services may be transmitted. 



5.2.2.2 ESG sessions configuration 

In case of DVB-SH full Transport Stream, the constitutive DVB services are by definition all common, and: 

• the distributed ESGs can only be non-regionalized, i.e. they strictly comply with DVB-H ESG phase 1 and 
phase 2. 

In case of DVB-SH partially available Transport Stream, the constitutive DVB services are common and local, and: 

• the distributed ESGs announcing common IPDC services but no local IPDC services are typically not 
regionalized (and then they strictly comply with DVB-H ESG phase 1 and phase 2) however they can be 
regionalized if it is also wanted to use local DVB services to carry complementing common ESG data 
(see ESG instantation mechanism 5); 

• the distributed ESGs announcing common and local IPDC services must be regionalized. 

One common DVB service has the particularity of carrying the ESG bootstrap FLUTE session of the single IP platform 
of the TS (indeed it is recognized by the terminal as being common due to this particularity). For each ESG Provider 
URI, this DVB service must also carry the common ESG announcement carousel, which declares ESG FLUTE sessions 
transporting fragments valid for this ESG on all cells where the TS is transmitted. In case other common DVB services 
are transmitted, they must not carry ESG announcement carousels. For a regionalized ESG instance, ESG 
announcement carousels may also be carried by local DVB services. For a given ESG (Provider URI for ESG phase 1, 
ESG_URI for ESG phase 2), there must be at most one local ESG announcement carousel transmitted. Via the ESG 
session partition declaration, each local ESG announcement carousel can announce: 

• at least all the ESG FLUTE sessions announced by the common ESG announcement carousel; 

• other ESG FLUTE sessions carried by transmitted local DVB services. 

For ESG phase 1: 

• The ESGEntries containing a given ProviderlD must be carried by one single ESGAccessDescriptor. The 
configuration recommended in TS 102 592-1 [2] (one single ESGProviderDiscovery descriptor, one single 
ESGAccessDescriptor) satisfies this model. 



• 



In this ESGAccessDescriptor, the ESGEntries containing the same ProviderlD must also appear as a 
continuous sequence in the ESG Entry loop. In this sequence, the ESG Entry declaring the common ESG 
announcement carousel must appear first. 
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For ESG phase 2: 

• The ESGEntries (Access Points) containing a given broadcast AccessPointID must be carried by one single 
ESGAccessDescriptor. 

• In this ESGAccessDescriptor, the ESGEntries containing the same broadcast AccessPointID must also appear 
as a continuous sequence in the ESGentry loop. In this sequence, the ESGentry (broadcast Access Point) 
declaring the common ESG announcement carousel must appear first. 

Figure 2 illustrates for both ESG phase 1 and ESG phase 2 the relationship between on the one hand a regionalized ESG 
advertised in the ESG ProviderDiscoveryDescriptor, and on the other hand the related ESG entries in the ESG 
AccessDescriptor which declare the common and eventually the local ESG announcement carousels: 
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Figure 2: Relationship between ESG bootstrap descriptors 

ESG FLUTE sessions declared from the current announcement carousel must all be available in the transmitted portion 
of the Transport Stream (said otherwise, the terminal never needs to check for the availability of an ESG FLUTE 
session declared from the selected announcement carousel). This implies in particular that an ESG FLUTE session 
declared from the common announcement carousel must always be carried by a common DVB service. 
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5.2.2.3 Delivery areas 



A delivery area is a conceptual area defined to achieve regionalization of ESG data while at the same time decoupling 
ESG data and ESG sessions from below-IP transport information (like DVB service_id) and network infrastructure 
information (like cell_id). 

For the ESG provider and service provider, a delivery area is a transport-agnostic and network-agnostic conceptual area 
where a well-defmed set of related ESG sessions and IPDC services are instantiated. Delivery areas are defined by the 
ESG provider, in the scope of one ESG instance (identified by ProviderURI for ESG phase 1 and by ESG_URI for ESG 
phase 2). 

For the Transport Stream originator or network provider, the delivery area is to be bound to an actual area of 
transmission in the DVB-SH network, i.e. in practice a subset of cells in the group of cells where the partially available 
Transport Stream is transmitted. The present document does not specify which entity in the network is in charge of 
defining this binding. 

For the (Type 2) terminal, the delivery areas are used in a more restrictive manner, for the basic purpose of determining 
which acquired fragments are valid on the current cell. Type and Type 1 terminals do not use delivery areas. 

The ESG providers must indicate to the entity building the TS the following: 

• For each IP stream (ESG sessions, other IPDC sessions), which ESG/delivery area ID pair(s) it belongs to. 

• For each ESG, what are the dependencies between the related delivery area IDs (e.g. area has no 
dependencies, area 1 has dependencies with area and area 500, etc.). 

From this information, the DVB services of the partially available Transport Stream can be safely constructed according 
to the following rules: 

• IP streams assigned to delivery areas with ID = (regardless of the ESG) must be carried by common DVB 

service(s). 

• IP streams assigned to delivery areas with ID ^^^ (regardless of the ESG) must be carried by local DVB 

service(s). 

• IP streams assigned to same ESG/same delivery area ID must be carried by one single DVB service. 

• IP streams assigned to same ESG/different delivery area ID must be carried by different DVB services. 

• IP streams assigned to different ESGs may be carried or not in same DVB service. 

• In the TS, the number of common DVB services and local DVB services should be minimal. 

In a last step, and given some specified binding between delivery areas and DVB-SH cells, it is possible to construct the 
SDT and the service_availability_descriptor (if relevant) for each service entry. 

Note that this binding is dynamic over time: 

• For a given ESG/delivery area defined by the ESG provider, the network entity in charge of the binding can 
decide to change TS identification or DVB service structuring or transmission cell selection, and this change is 
transparent for the ESG provider. 

• For a given network binding (TS identification, DVB service structuring, transmission cell selection), a change 
of distribution area definition by the ESG provider (addition or deletion of an IP stream, change in distribution 
area dependencies) are likely however to impact at least on the DVB service structuring. 

The delivery area is identified by 3-digit identifier (called "delivery area ID") unique in the scope of an ESG instance. 
Several ranges of values are defined: 

• 0: identifies the common delivery area targeted by the common announcement carousel. 

• 1 to 499: identifies a local delivery area targeted by a local announcement carousel. 

• 500 to 999: identifies a local delivery area targeted by no specific announcement carousel. This range allows 
some specific ESG instantiation mechanisms (6, 7 and 8). 
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For the range to 499 in the case of ESG phase 1, the delivery area ID represents the index of ESG Entry declaring the 
targeting announcement carousel, index starting from zero in the continuous sequence of ESGentries assigned to the 
ProviderlD. 

EXAMPLE: 

In the ESG ProviderDiscovery descriptor: 

ProviderURI=myProvl.com ProviderID=18 

ProviderURI=myProv2.com ProviderID=2 1 

ProviderURI=myProv3.com ProviderID=54 
In the ESG Access descriptor: 

ESGentry ProviderID=54 delivery area ID=0 for myProv3.com 

ESGentry 1 ProviderID=54 delivery area ID=1 

ESGentry 2 ProviderID=21 delivery area ID=0 for myProv2.com 

ESGentry 3 ProviderID=21 delivery area ID=1 

ESGentry 4 ProviderID=2 1 delivery area ID=2 

ESGentry 5 ProviderID=18 delivery area ID=0 for myProvl.com 

ESGentry 6 ProviderID=18 delivery area ID=1 

For the range 0..499 in the case of ESG phase 2, the delivery area ID represents the index of ESGentry declaring the 
targeting announcement carousel, index starting from zero in the continuous sequence of broadcast Access Points 
assigned to the "broadcast" accessPointID of the ESG. As an example: 

In the ESG ProviderDiscovery descriptor: 

ESG_URI=myProv 1 .com/ESG 1 "broadcast" accessPointID= 1 8 

ESG_URI=myProv 1 .com/ESG2 "broadcast" accessPointID=2 1 

ESG_URI=myProv3.com/ESG3 "broadcast" accessPointID=54 
In the ESG Access descriptor: 

ESGentry accessPointID =54 delivery area ID=0 for myProv3.com/ESG3 

ESGentry 1 accessPointID =54 delivery area ID=1 "" 

ESGentry 2 accessPointID =21 delivery area ID=0 for myProvl.com/ESG2 

ESGentry 3 accessPointID =21 delivery area ID=1 "" 

ESGentry 4 accessPointID =21 delivery area ID=2 "" 

ESGentry 5 accessPointID =18 delivery area ID=0 for myProvl.com/ESGl 

ESGentry 6 accessPointID =18 delivery area ID=1 "" 

5.2.2.4 IPDC services configuration 

Similar to DVB-H ESG phase 1 and phase 2, with the additional consideration that is the responsibility of the ESG 
provider to properly instantiate the ESG so that a terminal of any type (0, 1 or 2), using Acquisition fragments and 
related SDP files, is never in the situation where it attempts to tune to an IPDC stream for which there is no PID 
(i.e. case of a local IP stream not transmitted). If the ESG provider follows ESG instantation mechanisms described in 
clause 5.3, proper terminal implementations should not face this error situation. 
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5.2.2.5 Notification services configuration 

When the ESG phase 2 terminal supports the IPDC Notification Framework (TS 102 832 [7]), ESG instantiation must 
be done in such a way that the terminal should never face a situation where a local broadcast Notification session 
declared by a structure delivered in the current TS is not actually transmitted in the actual TS. In particular: 

• PDN channels must always be common IP streams. 



• 



• 



EDN channels must always be common IP streams. Incidentally this allows any Acquisition iragment 
(including local ones) to safely define the EDN channel as the default Notification Session. 

For a Notification Service (NS) declared as a Service fragment: this Service fragment and other related 
fragments (including the Acquisition fragment declaring the Notification session) can be instantiated as 
indicated in the scenarios of clause 2.5, applicable to any generic Service fragment and other related 
fragments. 

• For a Service Related Notification (SRN) service declared as a Notification component referred to by main 
Service via Notification Private Data: this main Service fragment and other related fragments (including the 
Acquisition fragment declaring the Notification component) can be instantiated as indicated in the scenarios of 
clause 2.5, applicable to any generic Service fragment and other related fragments. 

• For a Service Related Notification (SRN) service declared as a Service fragment referring to the main Service 
via RelatedMaterial: 

either the main Service must be common; or 

the main Service is local but must be delivered in same local Delivery Area as the local Notification 
service. 

5.2.2.6 Explicit ESG fragment regionalization 

Explicit ESG fragment regionalization is a mechanism that Type 2 servers can apply to individual ESG fragments of 
regionalized ESGs, to explicitly signal the delivery area of validity of these fragments. This signalling consists in 
storing the ID of this delivery area in the fragment ID (URI) of the fragment itself. More specifically: 

• The fragment ID of a regionalized fragment must be a valid URI. 

• Unless otherwise stated below, construction of this URI should follow the guidelines provided by 
TS 102 592-1 [2], clause "Identifiers within ESG XML fragments". 

• In the URI, the pattern 'area999' (without quotes) must immediately follow the URI scheme (and the double 
slashes '//' if any), where 999 represents the 3-digit delivery area ID value in decimal representation (059, 002, 
etc.). Valid examples are: 

somescheme : area059somecharacters 

dvbipdc : //area059 .myprovider/Channell/Contentl 

http : //area059 .myprovider . com/Channel 1/Contentl 

• In line with TS 102 592-1 [2], the present document does not mandate the use of a specific URI scheme in 
DVB-SH regionalized fragment identifiers. In any case, including the pattern 'area999' in the URI should 
satisfy the semantics defined by the URI scheme and should besides not trigger the obligation to register the 
area ID value with lANA or DVB, etc. In this regard, "urn:" scheme for a regionalized URI might not be a 
suitable choice, whereas "http:" scheme or "dvbipdc:" scheme (proposed in TS 102 592-1 [2]) would be. 

• In a regionalized ESG delivered over DVB-SH, all fragment identifiers must use the same URI scheme. This 
constraint is meant to ensure that 'area999' pattern is included at a fixed position in all fragment identifiers of 
the same ESG. 

For non-regionalized ESGs delivered over DVB-SH (instantiated by Type and Type 1 servers): 

• ESG fragments must not be explicitly regionalized (i.e. 'area999' pattern must not be found in fragment 
identifiers). 
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For regionalized ESGs delivered over DVB-SH (instantiated by Type 1 servers): 

• All fragment identifiers of the same ESG must use the same URI scheme. This constraint allows the terminal 
to find the 'area999' pattern (when present) at a fixed position in the fragment IDs of the same ESG. 

• All Service fragments of the ESG must be explicitly regionalized. This constraint is meant to enable proper 
definition and comparison of ESG session partitioning range values, as servicelD of Service fragment is one 
ESG session partition criterion: 

dvbipdc : //area059 .myprovider/Channell/ 
dvbipdc : //area059 .myprovider/Channel2/ 
dvbipdc : //area002 .myprovider/Channel3/ 

• ESG fragments other than Service fragments must be explicitly regionalized whenever ESG instantiation 
mechanisms in use require so (as per clause 5.3). 

• Otherwise, ESG fragments may or may not be explicitly regionalized. If a fragment is not explicitly 
regionalized, delivery area ID of validity will be implicitly inferred by the terminal (implicit ESG fragment 
regionalization). Systematically applying explicit regionalization to all fragments simplifies fragment identifier 
generation, whereas relying on implicit regionalization (when possible) saves transport bandwidth and 
terminal storage space (at least 7 bytes per fragment). 

5.2.3 Terminal behaviour 
5.2.3.1 ESG Bootstrap 

5.2.3.1 .1 Tuning to ESG Bootstrap session of preferred IP platform 

Identical to DVB-H ESG phase 1 and phase 2. 

5.2.3.1 .2 Selecting ESG provider URI from ESG ProviderDiscovery descriptor(s) 

Identical to DVB-H ESG phase 1 and phase 2. 

5.2.3.1 .3 Selecting ESG Entry from ESG Access descriptor(s) 

Identical to DVB-H ESG phase 1 and phase 2. 

5.2.3.1 .4 Tuning to ESG announcement carousel 

Identical to DVB-H ESG phase 1 and phase 2, with the following change for Type 1 and Type 2 terminals if multiple 
ESGentries of broadcast type are found for the same ESG (identified by Provider URI for ESG phase 1 and by 
ESG_URI for ESG phase 2): 

• In that case, this denotes a regionalized ESG. 

• Starting from first ESG Entry of broadcast type associated to a given ProviderlD (ESG phase 1) or 
AccessPointID (ESG phase 2), the terminal then determines for each ESG Entry if the associated ESG 
announcement carousel is transmitted or not, using an IP stream availability function. 

• The terminal stops parsing the ESGEntries if next ESG Entry is associated with another ProviderlD (ESG 
phase 1) or AccessPointID (ESG phase 2), or if two transmitted ESG announcement carousels are found. 

• If one single transmitted ESG announcement carousel is found, this is the common ESG announcement 
carousel, to be monitored. 
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• If two transmitted ESG announcement carousels are found, the terminal knows that the first one appearing in 
the loop is the common carousel, and therefore the other one is the local ESG announcement carousel, to be 
monitored. 

NOTE: The terminal can also identify the common ESG announcement carousel as the carousel carried by the 
DVB service transporting also the ESG bootstrap session. 

• From the position of selected ESG Entry in the ESG Entry loop, the terminal can infer the ID of the delivery 
area of the announcement carousel. 

5.2.3.2 ESG acquisition 

5.2.3.2.1 Selecting ESG FLUTE sessions from ESG Session Partition Declaration 

Identical to DVB-H ESG phase 1 and phase 2. 

5.2.3.2.2 Tuning to ESG FLUTE sessions 

Identical to DVB-H ESG phase 1 and phase 2. 

5.2.3.2.3 Using ESG indexing 

Identical to DVB-H ESG phase 1 and phase 2. 

5.2.3.2.4 ESG storage 

Identical to DVB-H ESG phase 1 and phase 2, with the following changes, in case the ESG instance is regionalized, as 
signalled by the presence of multiple ESGentries of broadcast type for the corresponding ProviderlD (ESG phase 1) or 
AccessPointID (ESG phase 2): 

For Type 1 terminals: 

• Implicit ESG fragment regionalization, which consists for Type 1 terminals in tagging each fragment with the 
identifier of the FLUTE session which delivered the fragment: 

How the terminal defines the identifier of a FLUTE session is implementation-dependent, however for a 
given ESG this identifier must be unique given the set of {IP version, source IP address, destination 
IP address, port, TSI} found in IPstreamID declaration. 

For Type 2 terminals: 

• Tagging of each stored fragment with the three-digit ID of the delivery area for which this fragment is deemed 
valid: 

(Implicit regionalization, for fragments other than Service fragments) The delivery area ID to be used 
for tagging is by default the ID of the delivery area of the selected carousel (inferred from ESG Entry 
position in entry loop of ESG Access descriptor). 

(Implicit regionalization, for fragments other than Service fragments) The delivery area ID determined 
in previous step is overridden by the delivery area ID inferred from the servicelD criterion of the 
partition which declares the ESG FLUTE session delivering the fragment, under the condition that this 
delivery area ID is well-defined, which is the case if: 

■ both 'start_field_value' and 'end_field_value' of servicelD criterion are URI starting by 
"dvbshipdc:" scheme (which implies the presence of 'area999' pattern); 

■ start_field_value and end_field_value express one single value (and not a range) of delivery area 
ID. 
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EXAMPLE: 

The delivery area ID would be equal to 001 if: 

start_f ield_value = "dvbipdc : //areaOOl .myprovider/" and 

end_f ield_value = "dvbipdc : //areaOOl .myprovider/Ch3 " 

But would be undefined whenever a range of arealDs is expressed: 

start_f ield_value = "dvbipdc : //areaOOl .myprovider/" and 

end_f ield_value = "dvbipdc : //area003 .myprovider/" 

Or when 'area999' is not following URI scheme: 

start_f ield_value = "dvbipdc : //myprovider . com/Chl" and 

end_f ield_value = "dvbipdc : //myprovider . com/Ch3 " 

(Explicit regionalization): The delivery area ID determined in previous step(s) is overridden when 
present by the delivery area ID explicitly signalled in the URI of the fragment ID itself (as defined 
above). 

5.2.3.3 ESG browsing and service consumption 

5.2.3.3.1 Displaying ESG information relevant to current location 

For Type terminal implementations, identical to DVB-H ESG phase 1 and phase 2. However, if the ESG provider 
uses ESG instantiation mechanisms 12 and 13, this type of terminal might attempt to purchase a service bundle which 
includes not only common services but also local services. 

• The first issue will be commercial: the user can purchase local services for which his or her terminal cannot 

access to. 

• The second issue will be operational: as a Type terminal does not implement any IP stream availability 
function, it will get an error when attempting to tune to non-transmitted local IP streams (declared by 
Acquisition fragments referenced by the local Service fragments parts of the service bundle). 

To avoid this situation: 

• ESG providers instantiating mechanisms 12 and 13 should describe the content of the service bundles very 
clearly. 

• Terminals of type might at a minimum check for the presence of a pattern /area999/ in the ID of the Service 
fragments part of a Service Bundle, and if the area ID is different from 000, do not propose the user to 
purchase this bundle. 

For Type 1 terminal implementations, identical to DVB-H ESG phase 1 and phase 2, with the following changes: 

• When tuned to a partially available Transport Stream, and subsequently to ESG selection, the terminal must 
determine the IDs of all the ESG FLUTE sessions declared in the ESG session partition declaration (all of 
them, not just the ESG FLUTE sessions of immediate interest for the terminal). 

• Knowing this list of FLUTE session IDs, the terminal should present to the user a current ESG subset made of: 

the ESG fragments currently stored in the terminal which are tagged by any of these FLUTE session IDs. 

• The terminal must in a second stage remove from this subset the fragments which are not valid in the current 
location. This can be done for instance as follows: 

First check for the actual validity of the Acquisition fragments of the subset, which consists in verifying 
(using an IP stream availability function) if all the IP addresses given in the related SDP are really 
transmitted in the actual TS. 
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Second discard from the ESG subset the invalid Acquisition fragments, as well as the invalid 
ScheduleEvent and Service fragments (i.e. which reference no valid Acquisition fragments), as well as 
the invalid Content fragments (i.e. which reference no valid Service fragment). 

For Type 2 terminal implementations, identical to DVB-H ESG phase 1 and phase 2, with the following changes: 

• When tuned to a partially available Transport Stream, and subsequently to ESG selection, the terminal must 
determine the IDs of the delivery areas it is currently located in. This list of delivery area IDs includes: 

the ID of the delivery area of the selected carousel, inferred from the position of the related ESG Entry in 
the ESG Access descriptor; 

the delivery area ID "zero" (if not already included in the list); 

any delivery area ID in range 500 to 999 encountered in "servicelD" partition criteria of the ESG session 
partition declaration. 

• Knowing this list of delivery area IDs, the terminal should present to the user a current ESG subset made of: 

the ESG fragments currently stored in the terminal which are tagged by any of these delivery area IDs; 

any other fragments referenced by these fragments, and then any fragments referenced by these other 
fragments, etc. ESG instantiation mechanisms described in the present document ensure that the chain of 
fragment references can always be resolved. 

• The terminal must in a second stage block the use of the referenced Acquisition fragments which are not 
tagged by delivery area IDs. 

• As an example, in ESG instantiation mechanisms 12 and 13, the terminal on satellite cell would present: 

the common ServiceBundle fragments; 

the common and local Service fragments referenced by these common ServiceBundle fragments; 

the Acquisition fragments referenced by the common Service fragments; 

the common "interactive" Acquisition fragments referenced by the local Service fragments; 

but would block the use of the local Acquisition fragments referenced by the local Service fragments. 

5.2.3.3.2 Accessing IPDC services from ESG 

Broadcast access to IPDC services is announced in the ESG, via Acquisition fragments and associated SDP files. At the 
time of service consumption, the question arises in which case the terminal should check (using an IP stream 
availability function) the availability of the related IP streams (audio/video streams, key streams, generic file delivery 
sessions, etc.) before tuning to them: 

• If the ESG is not regionalized. Type 0, Type 1 and Type 2 terminals do not need this check as a 
non-regionalized ESG always scopes common IP streams. 

• If the ESG is regionalized: 

A Type terminal implementation (which is not able to perform this check anyway) will safely tune to 
the announced IP streams, as all Acquisition fragments delivered in common area declare common IPDC 
services. 

A Type 1 terminal implementation must systematically check the availability of these IP streams. 

A Type 2 terminal implementation does not need to perform this check, as it is guaranteed that the 
Acquisition fragments tagged by a given delivery area ID declare IPDC streams distributed on this same 
deUvery area. 
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5.2.3.4 Mobility and acquisition service continuity 

For Type 0, Type 1 and Type 2 terminals moving to target cell where a different TS is transmitted: identical to 
TS 102 611-2 [i.4]. In most cases (and as signalled in the INT), very few IP streams should be common between source 
cell and target cell. It is unlikely also that a global ESG instance (identified by a ProviderURI) can be transmitted 
identically in two different Transport Streams, meaning ESG acquisition restart is expected when tuning on target TS. 
For Type terminals moving to target cell where same TS is transmitted: identical to TS 102 611-2 [i.4]. These 
terminals can only be tuned to IP streams carried by common DVB services, which are transmitted everywhere. Said 
otherwise, this is the handover case "same TS, change of cell_id, same or different network_id" based in NIT only. 

For Type 1 and Type 2 terminals moving to target cell where same TS is transmitted, two cases of ESG acquisition 
service continuity should be considered: 

1) The terminal is acquiring the ESG (and may consume IPDC services at the same time). 

If the set of DVB services transmitted on source and target cell are exactly the same, then handover can 
be performed on all received sessions (including the ESG ones). 

Otherwise, some ESG sessions are likely to differ from source cell to target cell, however a rerun of full 
ESG bootstrapping procedure on target cell should be avoided. Instead, the terminal should attempt to 
perform a handover on ESG sessions monitored on source cell, that are known to be transmitted on target 
cell. This typically includes the ESG bootstrap FLUTE session and the common ESG FLUTE sessions. 

The terminal should also attempt service continuity on the ESG announcement carousel, when possible. 
For this, various strategies are possible: 

a) The terminal could determine in advance (on source cell, before attempting handover) the IP 
address of ESG Announcement Carousel on target cell (according to ESG Access descriptor of 
common ESG bootstrap session, and using an IP stream availability function). This selection 
follows the principles of selection of ESG announcement carousel in actual TS. 

Two cases depending if IP addresses of source and target carousels are the same or not: 

If they are the same, service continuity for all ESG sessions (bootstrap, carousel and 
FLUTE sessions) should be attempted. 

If they are different, and since at least the ESG bootstrap FLUTE session and the 
common ESG FLUTE sessions are IP flows common to source and target cells, the 
terminal should attempt ESG acquisition service continuity on these, while tuning to 
target ESG Announcement Carousel in the background. In any case, a full ESG 
bootstrapping procedure should be avoided. 

b) Alternatively, the terminal could avoid determining in advance (on source cell) the ESG carousel 
on target cell, by always tuning to common ESG carousel when moving on target cell. In a second 
stage (on target cell in the background), the terminal would then determine if a local ESG carousel 
is transmitted, and tune to it if there is one. This method is quite efficient for the transitions: 

"satellite -^ terrestrial" (handover on common ESG carousel, followed by carousel selection 
procedure that will indicate the local ESG carousel to tune to). 

"terrestrial — > satellite" (tuning to common ESG carousel, followed by carousel selection 
procedure that will confirm common ESG carousel is the one to be tuned to). 

But is less efficient for the other transition: 

■ "terrestrial — > terrestrial, different ESG carousel" (tuning to common ESG carousel, followed by 
carousel selection procedure that will select a local carousel - transition thus involving two ESG 
carousel tunings on target cell). 

NOTE: Transition "terrestrial — > terrestrial, same ESG carousel" should occur in the situation "same DVB 
services transmitted on both source and target cell", for which there is no service continuity issue. 
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2) The terminal is not acquiring the ESG (but could consume IPDC services at the same time). 

The terminal should determine if the set of DVB services being transmitted has changed or not, from 
source cell to target cell. 

If it has not changed, the terminal may defer ESG bootstrapping and acquisition. 

If it has changed, the terminal could initiate ESG bootstrapping and acquisition. 

5.3 ESG instantiation mechanisms 

This clause describes how a complete ESG instance (identified by one ESG Provider URI in ESG phase 1 and by one 
ESG_URI in ESG phase 2) can be instantiated in a partially available Transport Stream. This description consists in a 
set of instantiation mechanisms which the ESG provider may combine to achieve various ESG distribution scenarios. 

For the clarity of the description, a few concepts are defined: 

• Current delivery area: in the scope of the selected ESG instance, delivery areas where a (Type 2) terminal is 
currently located. Current delivery areas are by definition bound to current cell. Practically, all the ESG and 
IPDC sessions instantiated in this delivery area are available to the (Type 2) terminal on current cell. The 
terminal may be located in several delivery areas at a time, and this list includes at least the delivery area of the 
selected carousel, as well as the common delivery area. 

• Neighbouring delivery area: delivery area scoped by the selected ESG instance, bound to a neighbouring cell 
but not to the current cell. The (Type 2) terminal can determine the presence of neighbouring delivery areas by 
checking the availability on neighbouring cells of local carousels different from currently selected carousel, 
using an IP stream availability function as well as the ESGentries of same ProviderlD (ESG phase 1) or same 
AccessPointID (ESG phase 2) in the ESG Access descriptor. 

• Valid fragment: ESG fragment which the terminal can safely present to the user with regard to the IPDC 
services available on the current cell. Technically, a fragment is valid if it is tagged by the ID of one of the 
current delivery areas. 



• 



• 



• 



Common fragment: ESG fragment valid in the common delivery area, i.e. on all the cells where the ESG 
instance is transmitted. 

Local fragment: ESG fragment valid in a local delivery area. 

Complete ESG: consistent ESG instance identified by one ProviderURI (ESG phase 1) or one ESG_URI 
(ESG phase 2). The complete ESG spans over one, several or all cells where the TS is transmitted. Typically, 
only self-contained ESG subsets of this complete ESG are transmitted on a given cell. 

ESG subset (or regionalized ESG): consistent subset of a complete ESG, aiming to announce the IPDC 
services available on a defined list of delivery areas. This subset is self-contained, i.e. fragments referenced by 
the fragments of this subset are also part of the subset. An ESG subset has no identifier. When moving from 
one cell to another, the terminal would typically acquire a new ESG subset. ESG subsets acquired in the 
different cells where the ESG is transmitted can be safely merged into the terminal so to construct the 
complete ESG. 

Current ESG subset: ESG subset delivered on the current delivery area(s) aiming to announce the IPDC 
services available on these delivery areas. 

Neighbouring ESG subset: ESG subset delivered on the current delivery area aiming to announce the IPDC 
services available on a neighbouring delivery area where the ESG instance is also transmitted. 

Common ESG subset: ESG subset aiming to announce the IPDC services available on common delivery area. 

Local ESG subset: ESG subset aiming to announce the IPDC services available on some local delivery 
area(s). 
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The described instantiation mechanisms pay special attention to ESG consistency, so to guarantee that any type of 
terminal cold-bootstrapping on any cell, and with no interaction channel capabilities, can still acquire a self-contained 
consistent ESG subset announcing all the IPDC services available on this cell. To achieve ESG subset consistency, the 
following rules apply: 

• A fragment distributed in a set of delivery area(s) can only reference fragments distributed in this set. 

• For a given ESG, fragments identified by a given pair {fragment ID, version} and distributed in delivery areas 
must all be equal bitwise. 

5.3.1 ESG instantiation mecinanism 1 



Title 


Delivering a common ESG subset, for minimal announcement of 
common programs (available everywhere) 


Usage 


A user cold-bootstrapping on satellite cell can discover all common programs, and 
purchase access to them. 


Implementations 


Server: Type and Type 1 . 
Terminal: Type 0, Type 1 and Type 2. 


Technical 
realization 


Common ESG subset is delivered by so-called common ESG FLUTE sessions, targeting 
common delivery area. Common ESG FLUTE sessions are announced by common ESG 
carousel, and must be announced also by each local ESG carousel. In order to save 
satellite bandwidth, common ESG FLUTE sessions are typically partitioned using « time » 
criterion, so to limit time depth of common ESG subset 
(e.g. < 3 days). 

Type 1 servers must explicitly tag common Service fragments with delivery area ID 'zero'. 
Otherwise (for other types of fragments), implicit ESG regionalization is sufficient. 


Comments 


For ESG consistency reasons, a common ServiceBundle cannot reference local Service 
fragments, so a mixed « common + local » Service Bundle cannot be part of this common 
ESG subset. This means that a terminal cold-bootstrapping on satellite cell would first 
subscribe to a common ServiceBundle, and when moving to a terrestrial cell, would then 
subscribe to a local ServiceBundle encompassing both common and local IPDC services. 
Note that common ServiceBundles should always be instantiated (even if common+local 
ServiceBundles are besides available on local areas) for two reasons: first, a Type 
terminal will never see the common-i-local ServiceBundles, second a Type 1 or Type 2 
terminal cold-bootstrapping on satellite must have a means to purchase access to the 
common IPDC services. 


Dependencies 


None. 


Status 


This mechanism must be used by ESG providers. 


Example 


See figure 3. 
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Figure 3: ESG instantiation mechanisms 1, 2, 3 and 4 
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5.3.2 ESG instantiation mecinanism 2 



Title 


Delivering a local ESG subset, for full announcement of local programs available on 

current terrestrial reception 


Usage 


The user can discover and access to all local programs available on current terrestrial 
reception. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 and Type 2. 


Technical 
realization 


The fragments of this local ESG subset are delivered in ESG FLUTE sessions belonging to 

the delivery area of the local « active >> ESG carousel. 

Type 1 servers must explicitly tag the local Service fragments with delivery area IDs in the 

range of 001 to 499. Otherwise (for other types of fragments), implicit ESG regionalization is 

sufficient. 


Comments 


When mechanisms 3 and 4 are not used, common and local ESG subsets are totally 
independent. Still, they are part of the same ESG instance, identified by ESG Provider URI 
(ESG phase 1) or ESG URI (ESG phase 2). 


Dependencies 


None. 


Status 


This mechanism must be used by ESG providers which announce local programs. 


Example 


See figure 3. 



5.3.3 ESG instantiation meclnanism 3 



Title 


Merging common and local service bundles 


Usage 


Reduce the number of service bundles presented to the user. Using this mechanism, one 
single (local) Service Bundle can encompass all common and local programs available on 
current terrestrial reception. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 and Type 2. 


Technical 
realization 


The same local ServiceBundle fragment is referencing common Service fragments as well as 
local Service fragments. 


Comments 


For ESG consistency reasons, the other way around is not possible (i.e. a common 
ServiceBundle fragment cannot reference local Service fragments). 


Dependency 


This mechanism needs mechanisms 1 and 2 to be deployed also. 


Status 


This mechanism should be used by ESG providers which announce bundles mixing common 
and local services. 


Example 


See figure 3. 



5.3.4 ESG instantiation meclnanism 4 



Title 


Sharing common Purchase Channel information 


Usage 


Reduce the number of PurchaseChannel entry points, while saving terrestrial bandwidth. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 and Type 2. 


Technical 
realization 


Purchase fragments delivered in local ESG FLUTE sessions can reference a common 
PurchaseChannel fragment. Transmission of PurchaseChannel fragments in local ESG 
FLUTE sessions can be avoided this way. 


Dependencies 


This mechanism needs mechanisms 1 and 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


See figure 3. 
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5.3.5 ESG instantiation meclnanism 5 



Title 


Complementing the common ESG subset on terrestrial path 


Usage 


On terrestrial cell, ESG announcement of common services is provided to user with a greater 
time depth (greater than on satellite cell). 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 and Type 2. 


Technical 
realization 


A local ESG FLUTE session carries fragments belonging to common ESG subset. In local 
ESG carousel, partition criteria for this FLUTE session are « servicelD » of a common ESG 
Service fragment, and « time » (e.g. > 3 days). Possible common fragments delivered in this 
FLUTE session can be Acquisition, Content and ScheduleEvent fragments. 
NOTE: Since common Service fragments are tagged by delivery area ID 'zero' (see 

instantiation mechanism 1), the servicelD criterion in local partition declaration is 

tagged by delivery area ID 'zero' as well. 


Comments 


Implicit ESG regionalization is sufficient for the fragments delivered this way. 


Dependencies 


This mechanism needs mechanisms 1 and 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


See figure 4. 
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Figure 4: ESG instantiation mechianism 5 



5.3.6 ESG instantiation meclnanism 6 



Title 


Announcing global terrestrial services 


Usage 


Some IPDC services not transmitted on satellite cell may happen to be available on most - if 
not all - terrestrial cells. Instead of instantiating these IPDC services in each local delivery 
area, a separate local delivery area can be defined to instantiate once these IPDC services, 
local delivery area to be bound to most terrestrial cells. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 and Type 2. 


Technical 
realization 


A global-terrestrial delivery area is specifically created for the distribution of programs 
available on most terrestrial cells but not on satellite cell. This delivery area instantiates also 
ESG FLUTE sessions with fragments announcing these programs, but no ESG 
announcement carousel. Instead, it is up to the ESG carousels of local-terrestrial delivery 
areas to announce these ESG FLUTE sessions. 


Comments 


Type 1 servers must explicitly tag global terrestrial Service fragments with delivery area IDs 
in the range of 500 to 999. Otherwise (for other types of fragments), implicit ESG 
regionalization is sufficient. 

Advantage of this mechanism is: better grouping of ESG data and IPDC service distribution. 
Drawbacl< is: increase of PMT bitrate on terrestrial path. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


S See figure 5. 
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Delivery Area 001 (Local) 
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Figure 5: ESG instantiation mechianisms 6, 7 and 8 



5.3.7 ESG instantiation meciianism 7 



Title 


Bundling local and global terrestrial services 


Usage 


Reduce the number of service bundles presented to the user. Using this mechanism, one 
local-terrestrial Service Bundle can encompass all local and global terrestrial programs 
available on current terrestrial cell. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 and Type 2. 


Technical 
realization 


The same local-terrestrial ServiceBundle fragment is referencing global-terrestrial Service 
fragments as well as local-terrestrial Service fragments. 


Comments 


For ESG consistency reasons, the other way around is not possible (i.e. a global-terrestrial 
ServiceBundle fragment cannot reference local-terrestrial Service fragments). 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism should be used by ESG providers. 


Example 


See figure 5. 



5.3.8 ESG instantiation meciianism 8 



Title 


Sharing global-terrestrial Purchase Channel information 


Usage 


Reduce the number of PurchaseChannel entry points. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 and Type 2. 


Technical 
realization 


Purchase fragments delivered in local-terrestrial ESG FLUTE sessions can reference a 
global-terrestrial PurchaseChannel fragment. Transmission of PurchaseChannel fragments in 
local-terrestrial ESG FLUTE sessions can be avoided this way. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


See figure 5. 
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5.3.9 ESG instantiation meclnanism 9 



Title 


Delivering a minimal local ESG subset of a neighbouring delivery area 


Usage 


Terminal is aware of the presence of a neighbouring delivery area (i.e. using ESG Access 
descriptor and IP stream availability function, it can determine the availability of another local 
announcement carousel on a neighbouring cell), and acquires silently on current local delivery 
area a minimal ESG subset valid for the neighbouring delivery area. When moving to 
neighbouring cell, the available programs can be presented immediately to the user using this 
minimal ESG subset. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 (must perform systematic IP stream availability 

check) and Type 2. 


Technical 
realization 


On the current local delivery area, the ESG carousel announces specific ESG FLUTE 
sessions delivering the ESG subset of the neighbouring delivery area. Type 1 servers must 
explicitly tag the local Service fragments of this ESG subset with delivery area IDs in the 
range of 1 to 49. Otherwise (for other types of fragments in this subset), implicit ESG 
regionalization is sufficient. 


Comments 


Implicit ESG regionalization is here sufficient. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism may be used by ESG providers. 


Example 


See Figure 6. 



Delivery Area 001 (Local) 



ESG Announcement Carousel 1 
IPstreamID 2 IPstreamID 5 

servicelD=/area001/Ch2 servicelD=/area002/Ch5 
time=all time<1h 




ScheduleEvent 



ServiceBundle 



PurchaseChannel \*-^ Purchase 
ESG FLUTE session 2 



ScheduleEvent ServiceBundle 



T 



PurchaseChannel ^ Purchase 
ESG FLUTE session 5 



Delivery Area 002 (Local) 

ESG Announcement Carousel 2 

IPstreamID 6 

servicelD=/area002/Ch5 
tinne=all 







Acquisition 




i 


• t 




Service iD=/area002/Ch5 | 




t 


k 


Content 


t 


ScheduleEvent ServiceBundle 


^ 


PurchaseChannel ^ Purchase 
ESG FLUTE session 6 


J 



Figure 6: ESG instantiation mechianisms 9 and 10 



5.3.10 ESG instantiation meclnanism 10 



Title 


Bundling the offering of IPDC services available in different local delivery areas 


Usage 


Reduce the number of service bundles presented to the user. Using this mechanism, one 
local Service Bundle can encompass programs of current local delivery area, and programs of 
a neighbouring local delivery area, for which local ESG subset is besides delivered in current 
local delivery area. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore). Type 1 (must perform systematic IP stream availability 

check) and Type 2. 


Technical 
realization 


A local ServiceBundle fragment in current local delivery area is referencing Service fragments 
delivered in this same delivery area, some being valid on current delivery area, others being 
valid in another local delivery area. 


Comments 


For ESG consistency reasons, the other way around is not possible (i.e. a global-terrestrial 
ServiceBundle fragment cannot reference local-terrestrial Service fragments). 


Dependencies 


This mechanism needs mechanism 9 to be deployed also. 


Status 


This mechanism should be used by ESG providers. 


Example 


See Figure 6. 
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5.3.1 1 ESG instantiation meclnanism 1 1 (not recommended) 



Title 


Passively delivering fragments of neighbouring local services 


Usage 


The user can quickly visualize which local programs are available when moving to a 
neighbouring local delivery area. 


Implementations 


Server: Type 1 . 

Terminal: Type (will safely ignore), Type 1 (must perform systematic IP stream availability 

check) and Type 2. 


Technical 
realization 


In the ESG FLUTE sessions of current local delivery area are also delivered a few fragments 
that are only valid for neighbouring delivery areas. These fragments are explicitly 
regionalized. The terminal stores them without too much reasoning. They may be used later 
to resolve dependencies between fragments (like IVIechanism 10) or to initialize ESG 
acquisition when moving to a neighbouring delivery area. 


Comments 


This mechanism is problematic because the servicelD which the neighbouring fragments 
relate to is not declared in the ESG partition declaration. Unless indexing is used, the terminal 
cannot know in which FLUTE session these neighbouring fragments are delivered. 
Also, these neighbouring fragments do not necessarily constitute a consistent subset on their 
own (although they might help local ESG subset of current delivery area(s) to remain 
consistent). Consistency can easily be broken. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism should not be used by ESG providers. 


Example 


See figure 7. 
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Figure 7: ESG instantiation mechanism 11 (not recommended) 
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5.3.12 ESG instantiation meclnanism 12 



Title 


Presenting everywhere some minimal information on all 
common and local IPDC services. 


Usage 


The user is presented with an elementary description of all common and local IPDC services 
(even on satellite cell). Further display indication shows which services are available or not on 
current cell. The user is even able to purchase a mixed bundle of common/local services on 
satellite cell. 


Implementations 


Server: Type 1 . 

Terminal: Type (must not display service bundles which include local services), Type 1 

(must perform systematic IP stream availability check) and Type 2. 


Technical 
realization 


A dedicated ESG FLUTE session Is instantiated in common delivery area to deliver all the 
local Service fragments available on local delivery areas for this ESG instance, as well as all 
the Acquisition fragments referenced by these Service fragments (for ESG consistency 
reasons). The servicelD partition criterion of this session expresses a range of local delivery 
area IDs. 


Comments 


All fragments delivered this way must be explicitly regionalized. 

Local Service and Acquisition fragments delivered on common delivery area must be totally 
identical as those delivered on local delivery areas. This implies that these local fragments 
are explicitly regionalized In both common and local services. 


Dependencies 


This mechanism needs mechanism 2 to be deployed also. 


Status 


This mechanism is encouraged to be used by ESG providers. 


Example 


See figure 8. 
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Figure 8: ESG instantiation mechanism 12 and 13 
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5.3.1 3 ESG instantiation meclnanism 1 3 (IPDC pinase 2) 



Title 


Giving alternative point-to-point access to local broadcast IPDC services on cells 
(especially satellite cell) where these local broadcast services are not available 


Usage 


On satellite cell, the user has no broadcast access to local TV channels, but can still access 
to them using point-to-point bearers. 


Implemen- 
tations 


Server: Type 1 . 

Terminal: Type (must not display service bundles which include local services), Type 1 

(must perform systematic IP stream availability check) and Type 2. 


Technical 
realization 


If the common ESG FLUTE session which delivers local Service fragments, a common 
Acquisition fragment of DeliveryChannel type "interactive" is delivered also, pointed by a local 
Service fragment. This Acquisition fragment is explicitly regionalized (i.e. acquisitionID 
contains the ID of common delivery area, i.e. zero). 


Comments 


All fragments delivered this way must be explicitly regionalized. 

For ESG consistency reason, "interactive" Acquisition fragments delivered in common 

delivery area must be delivered also on the local delivery areas where the local Service 

fragments are available (bitwise identical Acquisition fragments, meaning in particular tagged 

also by common delivery area ID). 

This instantiation mechanism is provided for information, as Acquisition fragments of 

DeliveryChannel type "interactive" are not in the scope of the present document. 


Dependencies 


This mechanism needs mechanisms 1 and 12 to be deployed also. 


Status 


This mechanism should be used by ESG providers when broadcast services not available on 
current cell are wanted to be accessed via interactive channel. 


Example 


See figure 8. 



5.4 Cinange summary from IPDC over DVB-H 

For ESG for DVB-SH, changes that are perceptible to an IPDC over DVB-H terminal implementation are the 
following: 

• For Type 0, Type 1 and Type 2 terminal implementations, if the ESG is not regionalized: none 

• For Type terminal implementations, if the ESG is regionalized: 

Display-level filtering of service bundles which include at least one local IPDC service. Practically, it 
means that terminal must hide ServiceBundle fragments which reference one or more local Service 
fragments (i.e. servicelD explicitly regionalized, with a delivery area ID in the range of 1 to 999). 

• For Type 1 and Type 2 terminal implementations, if the ESG is regionalized: 

Addition of an "IP stream availability function", which checks in the received TS the actual transmission 
of some given IP stream(s) of some given IP platform ID. For this check, this function especially relies 
on cell_id, INT and SDT/service availability descriptors. In the present document it is assumed to be a 
low-level function exposed to the application layer. 

ESG phase 1: in the ESGAccessDescriptor, multiple ESGEntries for the same ESG Provider ID. 
Selection of proper ESG Entry (i.e. ESG announcement carousel) made using IP stream availability 
function. 

ESG phase 2: in the ESGAccessDescriptor, multiple ESGEntries (broadcast Access Points) given for the 
same AccessPointID declared from an ESG (ESG_URI). Selection of proper ESGEntry (i.e. ESG 
announcement carousel) made using IP stream availability function. 

ESG fragment regionalization, consisting in tagging by an ID each stored fragment, according to implicit 
signalling (for Type 1 terminal: FLUTE session ID; for Type 2 terminal: delivery area ID given by ESG 
Entry position or by servicelD criterion) or explicit signalling (for Type 2 terminal: delivery area ID 
included in the fragment ID URI). 

User presented with a regionalized view of ESG according to the current FLUTE sessions transmitted for 
the selected instance (Type 1 terminal) or to the current delivery areas where the terminal is located 
(Type 2 terminal). 

Service continuity optimizations when terminal is acquiring the ESG while moving to another cell. 
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Annex A (normative): 

Types of ESG implementations 



This annex details several possible levels of ESG implementations for a DVB-SH ESG provider (ESG server) and for a 
DVB-SH terminal (ESG client). 

Types of server implementations: 



Type 


Deployed ESG mechanisms 


Related 
scenarios 


Type 


Strict instantiations of DVB-H IPDC ESG pliase 1 and ptiase 2. 


1 


Type 1 


Common and local announcement carousels, unlimited area-based 
fragment tagging, FLUTE sessions delivering valid fragments and 
(eventually) invalid fragments. 


1 to 13 



Types of terminal implementations: 



Type 


Supported mechanisms 


Type 


ESG client strictly conforming to DVB-H IPDC ESG phase 1 and phase 2, plus an eventual 
filtering on the presented service bundles (see clause 5.2.3.3.1). 


Type 1 


Selection of announcement carousel based on an IP stream availability function, FLUTE- 
session based fragment tagging, check of IPDC streams availability based on an IP stream 
availability function. 


Type 2 


Selection of announcement carousel based on an IP stream availability function, area-based 
fragment tagging. 



NOTE: Type 1 and Type 2 terminal implementations are assumed to achieve the same level of functionality. They 
just differ by the technical realization. 

These server and terminal implementations can co-exist with no interoperability issues. Table below indicates the 
limitations implied by some combinations: 



Server 


Terminal 


TypeO 


Type1 


Type 2 


Type 


OK 


OK 


OK 


Type 1 


OK, however terminal will not 
see the local IPDC services. 
Also terminal must implement 
a means to hide to the user 
the service bundles which 
include local IPDC services 
(security against potential 
deployments of instantiations 
mechanisms 12 and 13). 


OK, however terminal needs 
to check IPDC sessions 
availability. 


OK 



Recommended server implementations is: 

• Preferably Type 1 . 
Recommended terminal implementations are: 

• Preferably Type 2; 

• Eventually Type 1 if the terminal can implement a fast IP stream availability function. This speed is especially 
critical when the terminal needs to display the user which IPDC services are available on current cell (then the 
terminal needs to check for the availability of all the IPDC streams scoped by the Acquisition fragments 
tagged by the identifiers of the current ESG FLUTE sessions). 
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Annex B (informative): 

DVB-SH physical layer options for ESG 

B.1 SH-A SFN configuration 

As presented in figure B.l, the DVB-SH TS 1 being sent on the satellite will be received in exactly the same way 
wherever the terminal is located. 



Hybrid frequency 



Non-hybrid frequencies 



5 MHz 5 MHz 

F1 (satellite) | 1 



Satellite geographical area 
Same geographical local area 





TS1 


TS2 


TS3 


SH-A 


OFDM 


OFDM 


OFDM 


Modsat(celllDI) 


X 


- 


- 


ModCGCCcelllDD 


X 


- 


- 


Mod CGC (celllD 2-ter) 




K 


- 


Mod CGC (celllD 3-ter) 


- 




X 



Reception conditions 








Options 1 


DVB-H TS 


Unicast 


SFN Rx 1 


X 


X 


X 






SFN Rx 2 


X 


X 








SFN Rx 3 


X 










SFN Rx 4 




X 








SFN Rx 5 




X 


X 







Figure B.l : An example of SFN reception 



B.2 SH-A non-SFN and SH-B configurations 



Hybrid frequency 



Non-hybrid frequency 



M 

SMHl 


n ^■ 

SMHZ 5MHZ 






1 Fllsatsllitel 


1 F2rt?r1 1 F3(ter) | 



TS1 



TS2 



Satellite geographical area 
Same geographical local area 



SH-A non SFN 


OFDM 


OFDM 


OFDM 


SH-B non SFN 


TDM 


OFDM 


OFDM 


Mod sat (celllD 1 if OFDM) 
Mod CGC (celllD 2-ter) 
Mod CGC (celllD 3-ter) 


X (paTS sat semce) 
>! (paTS ter sen/ice) 


K 



Reception conditions 








Options 1 


DVB-H TS 


Unicast 


non-SFN Rx 1 


X 


X 


X 






non-SFN Rx 2 


X 


X 








non-SFN Rx 3 


X 










non-SFN Rx 4 




X 








non-SFN Rx 5 




X 


X 







Figure B.2: An example of non-SFN reception 
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